

# 消息队列防止消息丢失： 会把消息存在磁盘中

# 如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范

# 基于发布订阅的： 分布式消息系统

# KRaft 的核心组件 -----> 放弃zookeeper后
# Controller 节点	负责管理集群元数据（如 Topic/Partition 创建、Leader 选举等）。
# Broker 节点	处理生产者和消费者的请求，存储数据。
# Quorum 节点	由多个 Controller 节点组成，通过 Raft 协议保证元数据的一致性。
#     在 KRaft 模式下，Controller 和 Broker 可以部署在同一节点（推荐生产环境分离部署）


# 主要组件：
# Producer（生产者）：向 Kafka 发送消息的客户端。
# Consumer（消费者）：从 Kafka 读取消息的客户端。
# Broker（服务器）：Kafka 集群中的单个节点，负责存储和转发消息。
# Topic（主题）：消息的逻辑分类，生产者发送消息到 Topic，消费者从 Topic 订阅消息。
# Partition（分区）：每个 Topic 可以分成多个 Partition，提高并行处理能力。
    # 每个 Partition 是一个 有序、不可变 的消息序列。
    # 消息在 Partition 内按 偏移量（Offset） 索引。
# Replica（副本）：每个 Partition 可以有多个副本（Leader + Followers），提高容错能力。
# ZooKeeper（旧版本依赖）：管理集群元数据、Broker 注册、Leader 选举等（Kafka 3.0+ 逐步移除 ZooKeeper 依赖）。



# Topic
# Topic 是消息的逻辑分类，类似于数据库中的表或文件系统中的文件夹。
# 生产者（Producer） 将消息发布到指定的 Topic，消费者（Consumer） 订阅 Topic 来读取消息。
# 持久化存储：消息在 Topic 中按顺序持久化到磁盘，默认保留一定时间（如 7 天）或大小限制。
# 多订阅者支持：一个 Topic 可以被多个消费者组（Consumer Group）独立消费。
# 无消息删除：消息一旦写入 Topic，只能通过过期或压缩（Compaction）清理，不可随机删除。


# Partition
# Partition 是 Topic 的物理分片，每个 Topic 可以划分为多个 Partition。
# 每个 Partition 是一个有序、不可变的消息队列，消息按写入顺序分配一个递增的 Offset（偏移量）。
# 并行处理：
#     生产者可以同时向多个 Partition 写入消息，消费者可以并行读取不同 Partition，提高吞吐量。
#     一个 Partition 只能被同一个 Consumer Group 内的一个 Consumer 消费，实现负载均衡。

# 水平扩展：通过增加 Partition 数量，可以线性提升 Topic 的吞吐能力。

# 消息顺序性：
#     Partition 内部的消息是有序的，但 跨 Partition 的消息不保证顺序。
#     如果需要全局顺序，可以将 Topic 设为单 Partition（但会牺牲并发性能）。-------- 同一个商户的消息写道同一个partition中

# Partition 的存储：每个 Partition 对应一个磁盘上的日志文件（Log Segment），包含：
#     .log 文件：存储实际消息。
#     .index 文件：加速 Offset 查找。
#     .timeindex 文件：按时间戳查找。



# broker 是 Kafka 集群中的一台服务器，负责存储消息、处理生产者和消费者的请求。一个 Kafka 集群由多个 Broker 组成，共同承担负载
# 消息存储:每个 Broker 存储一部分 Partition 的数据
# 请求路由:生产者/消费者连接到任意 Broker（通过 bootstrap.servers 配置），由 Broker 返回集群元数据（如 Partition Leader 位置）
# 副本管理: 每个 Partition 有多个副本（Replica），分为：Leader：处理所有读写请求; Follower：从 Leader 同步数据（备用）;通过 ISR（In-Sync Replicas） 机制保证数据一致性
# Broker 扩展性：水平扩展：通过增加 Broker，可以：存储更多数据（每个 Broker 承担部分 Partition）。提升集群整体吞吐量。
# 高吞吐与低延迟 
#     1. 单机可支持 每秒百万级 消息写入（取决于硬件配置）； 廉价机器也可支持 10万
#     2. 批量发送（Batch）、零拷贝（Zero-Copy）等技术优化性能
                            # 零拷贝： 
                            #   mmap ：0用户空间拷贝： 磁盘 到 内核缓冲区  到 socket 缓冲区
                            #   sendfile： 0 cpu拷贝， 数据从磁盘到缓冲区，直接到网卡 ----  使用的 DMA

# 消息持久化:采用时间复杂度O(1)的磁盘存储结构，即使TB级以上数据也能保证常数时间的访问速度




# 使用场景
# 实时数据管道 ： 将数据从源系统（如数据库、日志）实时传输到数据仓库（如 Hadoop、Snowflake）。
# 事件驱动架构：微服务间通过 Kafka 解耦，实现异步通信（如订单处理、用户行为跟踪）。
# 日志聚合：集中收集分布式系统的日志（替代 ELK 中的 Logstash）。
# 消息队列：替代传统 MQ（如 RabbitMQ），尤其适合高吞吐场景。


# https://www.bilibili.com/video/BV1gm4y1w7tN/?spm_id_from=333.337.search-card.all.click&vd_source=55a70ceabdb66cf8fe463891b9b7b436

# 网络超时环境下 --- 顺序消息影响问题
# 下单 ---- 支付  ----- 完成  ：   支付 和 完成 都是更新下单的状态， 如果下单没有成功， 支付和完成如法被发送
#         1. 失败重试： 使用es job 简历消息重试机制  ---- 重试一定次数 都不能成功需要报错
#         2. 如果下单失败 ：  使用 异步 重试（不会阻塞后面消息） ---  异步消息处理需要报错到专门的表中（重试表）
#                     此时来了 支付  ---  因为下单没有备消费支付不能备消费 ----- 
#                                     消费者消费-----先查询重试表是否有这个订单消息，如果有直接保存到重试表 
#                                             --  如果重试表没有相关数据， 直接进行业务处理


# 生产者  ---一次网络io----  broker -----磁盘io------ 数据写入磁盘 ------消费消息------ 需要一次磁盘io--一次网络io
# 消息体过大：只 发送简单的数据，如 id 等简单的信息， 消费时再去响应库中查询具体数据


# 数据倾斜问题： 如某几个商家消息特别多，分配到了同一个partition 导致消息积压， 可以使用订单号均衡发，


# 临时突发：活动导致流量激增，此时无法通过增加 partition 解决
# 1. 查看topic数据查看消息是否积压，看看每个partition 有多少积压
# 2. 查看服务监控 看消费者挂了没
# 3. 查看服务日志是否有日常

# 使用线程池 增加 线程数量结局消费问题  ==== > 导致相关系统 压力激增

# 对于严格要求消息顺序的场景：将线程池改为多个队列

# 高并发查询插入问题： 主键冲突
# insert into table (column_list) values(value_list) on duplicate key update k1 = v1, k2=v2    -------  支持幂等设计

# 主从消息延迟问题： 使用重试表解决.



# 消费消息模式
# At-Most-Once：消息最多被消费一次，可能会丢失，但绝不会重复；消费者在实际处理消息前就提交 Offset，若后续处理失败，消息不会被重新消费
        # 日志采集：原始日志可容忍少量丢失（如监控埋点数据）
        # 非关键指标统计：如页面浏览量（PV）统计，少量丢失不影响整体趋势
        # 高吞吐低延迟需求：牺牲可靠性换取更高吞吐量（如 IoT 设备数据上报）

# At-Least-Once：可能重复，不丢失	大多数业务场景（默认推荐）
# Exactly-Once：不丢失不重复	金融交易、对账和结算系统


# 消费串了，可以使用 重置 offset 进行重新读取部分消息

# kafka的 consumer 使用自动确认机制导致 cpu 100%




# ----------------------------------------------------------

# kafka 数量 = 2 * （峰值生产速度 * 副本数 / 100) + 1   ： 吞吐再 50M/s 需要3台kafka集群
# kafka 压测： kafka-consumer-perf-test.sh 
# 副本一般2个；默认保存7天，生产建议3天
# 硬盘大小100G(日) * 2(副本) * 3(天) / 0.7 = 857G；  日增100G 需要1T磁盘
# ack ： -1 主从都同步成功返回，各个节点都收到数据才发下一条； 1 只有主节点成功，主节点收到就返回； 0 发出去不管收到没收到
# kafka 消费跟不上生产速度： 增大分区；增加消费
# 分区内有序，分区间无序
# kafka传输块： 分布式集群；采用分区；顺序读写代替随机读写；零拷贝



# --------------------------------------------------
# 公司新闻、风险舆情时间